Devices, such as mobile phones, desktop computers, laptops, tablets, and so on, may have their configuration controlled by an organization to ensure that the devices comply with the policies of the organization. For example, a company may control the configuration of mobile phones that its employees use to conduct business to ensure that sensitive information of the organization is not compromised. An organization may employ a configuration source (e.g., a program executing on a server) to manage the configuration of the devices. The configuration sources may include a Mobile Device Management (“MDM”) system, Microsoft's Group Policy, Microsoft's System Center Configuration Manager, messaging servers (e.g., to synchronize emails, contacts, calendars, tasks, and notes), a classroom orchestration server, and so on. When a device enrolls with a configuration source, the configuration source provides to the device configuration information for configuring the device. The configuration information may include, for example, password requirements (e.g., 8 characters and at least one number and one letter), encryption requirements (e.g., encrypt all emails stored on the computing device), device lock requirements (e.g., lock device after 10 minutes of inactivity), email content requirements (e.g., add a legal notice to all emails), access control rights (e.g., administrator or user privilege), and so on. A program executing on a device ensures that the device operates in accordance with its configuration to ensure compliance with the policies of the organization.
Sometimes a device may have its configuration controlled by multiple configuration sources. For example, an organization may use one configuration source to control access rights to documents, another configuration source to control device security, and another configuration source to control installation of programs. With multiple configuration sources, conflicts between the configuration information of configuration sources can occur. For example, two configuration sources may specify configuration information indicating to encrypt emails, but with different types of encryption. The resolution of such conflicts resulting from multiple configuration sources can be a challenge.
The configuration sources used by an organization may need to support multiple types of hardware and software platforms. For example, the central processing unit of one device may support advanced security features (e.g., a secure cryptoprocessor), while other devices do not support such features. As another example, the devices may use different operating systems and even different versions of the same operating system. An organization may need to employ many configuration sources to support these hardware and software platforms and to manage separate policies for each platform. This management of separate policies is expensive and prone to error.
With multiple configuration sources and platforms, an organization may want to migrate devices from a set of current configuration sources to a set of new configuration sources. To perform such a migration, the devices are first un-enrolled from the current configuration sources and then enrolled with the new configuration sources. From the start of the un-enrollment until the completion of the enrollment, the policy of the organization may not be completely enforced, leaving a device vulnerable to a compromise. For example, if a device is un-enrolled from a configuration source that specifies not to install a certain application, the application may be installed in the time between the un-enrollment and enrollment in the new configuration source that specifies not to install that application.